[レポート][ARC306-R1] マルチリージョンのデザインパターンとベストプラクティス #reinvent

はじめに

こんにちは、CX事業本部、re:Invent 2022 現地参加組の田中孝明です。

セッション概要

ARC306-R1: Multi-Region design patterns and best practices

このセッションでは、マルチリージョンデザインのトピックを深く掘り下げ、そのようなアーキテクチャを実装するためのさまざまな方法を探ります。マルチリージョンアーキテクチャをどのように考えるか、またコスト、運用、エンジニアリングの観点から何が含まれるかを検討します。また、Amazon Route 53 Application Recovery Controller、Amazon CloudFront Functions、Amazon Aurora Global Database、Amazon DynamoDB global tablesなど、マルチリージョンソリューションの構築を支援するAWSサービス機能についても学びます。

セッション

リージョン間に依存することなく運用を続けるにはどうすればいいのかということが重要なポイント。フェイルオーバーメカニズムはアーキテクチャそのもの。

スタンバイ領域からフェイルオーバープロセスを実行できるようにしたいです。そして、完全に独立していることを確認するために、どのようにソリューションを構築するかを検討します。このように、目的に応じたサービス機能を提供しています。5つの地域別エンドポイントを提供し、プライマリー地域に依存することなく、安全かつ確実にフェイルオーバーを起動することができます。

一定期間通常のトラフィックを受け入れ、それがすべて完了したら、セカンダリに移して観測できるようにします。ここで重要なのはどのレプリカを複製するか、どのメトリクスを複製するかということです。一般的には、ユーザー体験、メトリクス、ユーザーアカウントのトランザクションなど、より高次のメトリクスと、レプリケーションラグに関連する単一リージョンでの新しいメトリクスを考える必要があります。

プライマリとスタンバイの間で、データ同期がどの程度遅れているかを把握したいですし、プライマリでアプリケーションの状態を監視し、ファームリージョンでアプリケーションの状態を外部から確認したいのです。この遠隔測定は、健全性を理解するのに役立ち、フェイルオーバーの決定プロセスのためのインプットとなります。

フェイルオーバーの範囲も考えなければなりません。これはマイクロサービス・アーキテクチャになるほど複雑になりますが、チームが信じられるフェイルオーバーを行えるように決定する必要があります。

コストと複雑さについても触れたいと思います。最初の要件の基本で述べたように、多くのエンジニアリングの労力が必要です。新しい人が入ってくると、運用上のオーバーヘッドが発生します。フェイルオーバーのプロセスを確立し、フェイルオーバーを定期的にテストする必要があります。 RPOが低く、2つのシナリオがある場合、通常、インフラストラクチャの評価やトラフィックが短期間で2倍になることが分かっています。 しかし、運用の手間やエンジニアリングの手間も増えます。たとえば、ビジネス向けの機能を構築する際に、複数の地域向けに再設計する必要が出てくるかもしれません。

数年前からバンガード社で継続的なソリューションの導入と設計を行っています。 私たちはユーザー・エクスペリエンスを向上させたいと考えています。キャッシュを試したり、思考型AIを導入したり、アプリケーションストリーミングを行ったり、どれもある程度は役に立っていますが、データをお客様の近くに移動させることで得られるメリットに勝るものはありません。

もうひとつは、高可用性です。これはディザスターリカバリーの話ではありません。私たちが求めていたのは、復旧可能な程度の障害ではなく、ユーザーに大きな影響を与えない程度の障害でした。それを達成できたかどうかは、影響が大きいか小さいかだと思います。

ハブ＆スポーク。これは集中型のモデルです。 たとえば、リスク管理チームがたくさんの計算を行うとします。そして、それらの計算は世界中に分散しており、複数の拠点を使用しています。アメリカにある集中管理された拠点が毎日更新を行い、それがそのまま移動する時間です。

このような取引を行うために、トレーダーは世界中に散らばっています。まず、オーストラリアのトレーダーから始めますが、彼らは一日の仕事の最初にやってきます。彼らは、ほとんどの取引に対応できるよう、データへの高速な読み取りと書き込みのアクセスを求めています。太陽が地球の周りを回るように、私たちはイギリスに移動しました。そこではトレーダーがオンラインになり、データへの高速な読み取りと書き込みを希望しています。そして、日中に太陽がさらに移動すると、米国がオンラインになり、同様にデータへの高速な読み取りと書き込みアクセスが可能になります。これが、「太陽の通り道」と呼ばれる所以です。

AWS Transfer for SFTP や Amazon S3 を使ってデータを提供する企業がよくあります。

2つの異なるリージョンで AWS Transfer for SFTP をセットアップしました。

その上に Route 53 のフェイルオーバー・ルーティングを配置しました。

ベンダーはそのURLに書き込むことができ、2つのリージョンのいずれかに送られます。 AWS Transfer for SFTP が S3バケット に書き込み、そのデータは世界中にレプリケートされます。そして、それを瞬時に実行します。

コスト面では、増加の一途をたどっています。これはよく言われることですが、高価なソリューションです。私たちは通常、その2倍の量のインフラを稼働させています。 ビジネス・ケースの観点からは、このインフラを導入することで1件の事故を回避できます。 私たちは、ユーザーエクスペリエンスと可用性を確保するために必要な要件を理解しています。

マルチリージョンに行く前に考えることができる、より広いパターンとは何かを見ていきます。

マルチリージョンを考えるには、アクティブかパッシブか、2つの方法があります。

すべてのユーザーが読み書きするトランザクションはプライマリーリージョンに送られ、プライマリーリージョンでサービスが停止した場合に備えてパッシブリージョンまたはスタンバイリージョンが用意されています。 アクティブ・アクティブにはさまざまなやり方があります。作業負荷に応じて複数のリージョンを使って、より多くのリージョンに配置することです。特にグローバルに分散したい作業負荷がある場合です。

パイロットライトのように、セカンダリーリージョンですべての構成コードのインフラを利用できるようにすることができます。 そして、実際にフェイルオーバーするときには、コンピュート・リソースを立ち上げ、そのキャパシティをセカンダリーリージョンのトラフィックを受け始めるために使用できるようにします。 もう1つはこのパターンで待機しており、試験的に構築し、2番目のリージョンにはすでに利用可能な容量があります。 フェイルオーバーが発生した場合、トラフィックの供給を開始し、そこからスケールアップしていくことができます。 ホットスタンバイはその次のステップで、セカンダリーリージョンでもプライマリージョンとほぼ同じインフラとキャパシティを稼働させることができます。

Amazon Auroraグローバルデータベースのようなものを使っている場合、地域横断的にデータベースを配置することができます。この場合、データは非同期レプリケーションとなります。どの戦略を選ぶかによりますが、バックアップとリストアの点から始めて、自由にプライマリーリージョンのバックアップを取り、それをセカンドリージョンですぐに利用できるようにすることも可能です。 継続的レプリケーションを行うか、バックアップとリストアを行うか、どちらの戦略を取るかは、事業継続戦略の一環として私たちが障害回復ポイント目標をどのように設定するかというように、RTOの要件によって決定されるでしょう。

アクティブ・アクティブを行う方法は一つではありません。

1つの方法として、リージョナル・シャーディングがあります。これは、ユーザーをそれぞれの地域にマッピングさせるということです。これは、グローバルに分散したワークロードです。

このパターンでは、ユーザーはトランザクションを書き込むために常に1つのリージョンに行きますが、読み込みトランザクションを異なるリージョンに分散させることができます。地理的に分散したワークロードや、レイテンシーに敏感なワークロードで読み取りが多い場合、これが役立つ別のユースケースとなるでしょう。

このパターンでは、最終的な一貫性について話しています。レプリケーションの遅延がどのようなものであれ、ワークロードが持続するかどうかを考える必要があります。

このパターンのもう一つのバリエーションは、地域間の強力な一貫性を実際に構築することです。このパターンには少し注意が必要です。特に、レイテンシーの問題があります。

地域から地域Bに同期して書き込むという方法もあります。この場合、別の種類の複雑さがあります。データの一貫性をどのように確保し、リージョンを通過させるかは、アプリケーションのロジックに起因します。

読み込みと書き込みのトラフィックを異なるリージョンに分散させる場合です。複数のノードを持っている分散システムにも当てはまりますが、一貫性の観点から競合の解決について考える必要があります。

Route 53 (Application Recovery Controller) がプライマリからセカンダリへのトラフィックの移行や、それに伴う準備状況の確認など、あらゆることをコントロールすることができます。 アクティブ・アクティブ・シナリオでは、地域間で複雑なルーティングが行われます。

Amazon CloudFront には、Lambda@Edge という機能があり、興味深いことができます。 受信したクッキーを検査したり、リクエストを検査したりすることができるのです。 アプリケーションが返してくるHTTPコードも調べられます。 これを組み合わせることで、アプリケーションや、特定のユーザーを異なる地域のアプリケーション・スタックにマッピングするシナリオで役に立つかもしれません。

3つ目は、 AWS Global Accelerator です。マルチリージョンやシングルリージョンのルーティングのほかに、レイテンシーを向上させるという利点もあります。 AWS Global Accelerator は、AWSのバックボーンを通過するため、トラフィックを高速化することができます。 アプリケーションをデプロイするさまざまな地域に対して、非常に迅速にアクセスすることができます。 地域ごとに異なるエンドポイントにトラフィックをどのように分散させるか、非常に細かく制御することができます。

マルチリージョンは複雑になる可能性があります。あなたのユースケース、ワークロードによって適切なパターンを選択する必要があります。

所感

金融系でなぜマルチリージョンにしなければならないかの内情や、各種デザインパターンの紹介などマルチリージョンでシステムを構築する際の注意点などが話されていました。 なかなかそういう機会には遭遇しないですが、知識として取り込んでおくと良さそうなセッションでした。